4-2. 컨테이너를 다루는 도구, 도커(Docker) - 파트 2

4.7. 컨테이너와 프로세스: 프로세스별로 컨테이너 나누기

4.7.1. 하나의 컨테이너에 하나의 프로세스가 기준

컨테이너는 본질적으로 프로세스와 동일함. 따라서 여러 응용 프로그램을 같은 컨테이너에 넣을지는 **"이들을 일반적으로 같은 프로세스로 실행하는가"를 기준으로 판단할 수 있음.

예를 들어 웹 시스템을 웹 서버 / AP 서버 / DB 서버의 3계층으로 구성한다고 하면, 한 컨테이너 안에서 세 프로세스를 모두 실행할 수도 있지만 일반적으로 세 서버는 별도 프로세스로 실행함. 따라서 프로세스마다 3개의 컨테이너로 나누는 것이 바람직함.

3계층 웹 시스템의 컨테이너 분리:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[한 컨테이너에 몰아넣기]           [프로세스별로 분리 — 권장]
┌────────────────────┐          ┌────────┐ ┌────────┐ ┌────────┐
│   웹 + AP + DB      │          │ 웹 서버 │ │ AP 서버 │ │ DB 서버 │
│   (3개 프로세스)     │          │ 컨테이너 │ │ 컨테이너 │ │ 컨테이너 │
└────────────────────┘          └────────┘ └────────┘ └────────┘
 ✗ 병목 시 개별 확장 불가           ✓ 병목 컨테이너만 여러 대로 확장
 ✗ 공유 리소스 경합 위험            ✓ 프로세스 격리로 경합 방지

4.7.2. 프로세스별로 컨테이너를 나눌 때 장점

용어 정리

  • 경합 상태 (Race Condition): 여러 프로세스·스레드가 공유 리소스에 동시에 접근할 때 실행 순서에 따라 결과가 달라지는 상태. 재현이 어려운 버그의 원인

4.7.3. 프로세스별로 컨테이너를 나눌 때 단점

4.7.4. 볼륨이란

컨테이너를 삭제하면 컨테이너의 데이터도 사라짐. 데이터를 남겨 두고 싶으면 **도커 볼륨(Volume)을 사용해야 함.

바인드 마운트(Bind Mount)는 볼륨과 비슷하지만 호스트 운영 체제의 파일 시스템을 컨테이너에 마운트한다는 점이 다름. 파일 시스템 공유는 가능하나 제약이 많으므로, 컨테이너 간 공유에는 볼륨이 더 나음. 바인드 마운트는 주로 호스트와 컨테이너 간 파일 시스템 공유에 사용함.

용어 정리

  • 볼륨 (Volume): 컨테이너가 읽고 쓰는 데이터를 지속화하기 위해 도커가 관리하는, 이름이 붙은 디렉터리
  • 지속화 (Persistence): 프로그램이 종료되어도 데이터가 손실되지 않도록 저장하는 것
  • 바인드 마운트 (Bind Mount): 호스트 OS의 특정 경로를 컨테이너에 직접 마운트하는 방식

볼륨 vs 바인드 마운트:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[도커 볼륨]                          [바인드 마운트]
┌───────────┐  ┌───────────┐        ┌───────────┐
│ 컨테이너 A │  │ 컨테이너 B │        │  컨테이너  │
└─────┬─────┘  └─────┬─────┘        └─────┬─────┘
      └──────┬───────┘                    │
             ▼                            ▼
   ┌────────────────────┐      ┌────────────────────┐
   │ 도커가 관리하는      │      │ 호스트 OS의 임의     │
   │ 전용 디렉터리(이름)  │      │ 경로(파일/디렉터리)  │
   └────────────────────┘      └────────────────────┘
   → 컨테이너 간 공유에 적합       → 호스트 ↔ 컨테이너 공유에 사용
   → 제약이 적음                  → 제약이 많음
구분 도커 볼륨 (Volume) 바인드 마운트 (Bind Mount)
저장 위치 도커가 관리하는 전용 디렉터리 호스트 OS의 임의 경로
관리 방식 이름으로 관리 (도커가 관리) 호스트 경로를 직접 지정
주 용도 컨테이너 간 파일 시스템 공유·데이터 지속화 호스트 ↔ 컨테이너 간 파일 공유
제약 적음 (권장) 많음

4.8. 네임스페이스

4.8.1. 네임스페이스란

4.8.2. 네임스페이스와 컨테이너

도커는 네임스페이스를 이용해 다른 컨테이너와 격리함.

네임스페이스에 의한 컨테이너 격리:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

              [도커 데몬]
                  │ 컨테이너를 실행할 때마다
                  ▼
   ┌───────────────────────────────┐   ┌────────────────┐
   │  네임스페이스 A (컨테이너 A)    │   │ 네임스페이스 B  │
   │  ┌────────┐   ┌────────┐      │   │ (컨테이너 B)    │
   │  │ 최초    │→ │ 자식    │ ...   │   │  ┌────────┐    │
   │  │ 프로세스│   │ 프로세스│      │   │  │  ...    │    │
   │  └────────┘   └────────┘      │   │  └────────┘    │
   │  → 내부에서 외부가 보이지 않음  │   └────────────────┘
   └───────────────────────────────┘
   "보이지 않는다면 없는 것과 같다" — 필터 역할

4.8.3. 네임스페이스에 의해 격리된 리소스

네임스페이스는 다양한 리소스를 격리할 수 있음. 예를 들어 PID 네임스페이스는 프로세스 ID를 격리해 다른 컨테이너에서 동일한 프로세스 ID를 사용할 수 있게 하고, 네트워크 네임스페이스는 네트워크 인터페이스와 포트 번호를 격리해 컨테이너마다 다른 IP 주소를 할당할 수 있게 함.

네임스페이스 격리하는 리소스
PID 네임스페이스 프로세스 ID
네트워크 네임스페이스 네트워크 인터페이스, 포트 번호
IPC 네임스페이스 프로세스 간 통신
마운트 네임스페이스 파일 시스템
UTS 네임스페이스 호스트명

4.8.4. 컨트롤 그룹이란

용어 정리

  • 네임스페이스 (Namespace): 리소스를 "보이지 않게" 하여 프로세스를 격리하는 리눅스 커널 기능
  • 컨트롤 그룹 (cgroups): 프로세스 집합이 사용하는 하드웨어 리소스(CPU·메모리·디스크 I/O 등) 사용량을 제한하는 리눅스 커널 기능

4.8.5. 컨트롤 그룹의 계층 구조

격리(네임스페이스) vs 제한(컨트롤 그룹):
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[네임스페이스] — "보이지 않게"        [컨트롤 그룹(cgroups)] — "얼마나 쓸지"
├─ PID (프로세스 ID)                 ├─ CPU 코어 수
├─ 네트워크 (인터페이스·포트)         ├─ 메모리 용량
├─ IPC (프로세스 간 통신)            └─ 디스크 I/O
├─ 마운트 (파일 시스템)
└─ UTS (호스트명)                    계층 구조 (cgroupfs)
                                    └─ 상위 제한을 하위가 상속 · 초과 불가

4.9. 차분 관리

4.9.1. 차분 관리란

4.9.2. 이미지 레이어의 특징

4.9.3. 컨테이너 레이어의 특징

이미지 레이어와 컨테이너 레이어:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

 ┌──────────────────────────────┐
 │  컨테이너 레이어 (쓰기 가능)   │ ← 컨테이너와 함께 생성·삭제
 ├──────────────────────────────┤
 │  이미지 레이어 3 (읽기 전용)   │ ┐
 ├──────────────────────────────┤ │ 각 레이어는 직전 레이어와의
 │  이미지 레이어 2 (읽기 전용)   │ │ '차분'만 기록
 ├──────────────────────────────┤ │
 │  베이스 이미지 레이어 (읽기전용)│ ┘
 └──────────────────────────────┘

[파일 쓰기 — 카피 온 라이트(Copy-on-Write)]
 이미지 레이어의 파일 수정 요청
   → 파일을 컨테이너 레이어로 복사한 뒤, 복사본을 변경

[파일 읽기]
 모든 레이어에서 대상 파일을 검색 → 가장 새로운 버전을 읽음
구분 이미지 레이어 (Image Layer) 컨테이너 레이어 (Container Layer)
쓰기 가능 여부 읽기 전용 (변경 불가) 쓰기 가능
생성 시점 이미지 빌드 시 컨테이너 실행 시
라이프 사이클 이미지에 귀속, 재사용됨 컨테이너와 동일 (삭제 시 함께 삭제)
기록 내용 직전 레이어와의 차분 프로세스가 추가·변경한 파일

4.9.4. 차분 관리의 장단점

장점

단점

4.10. 스웜 모드

4.10.1. 스웜 모드란

4.10.2. 매니저와 워커

도커는 스웜 내 노드에 매니저 / 워커 / 매니저 겸 워커 세 역할 중 하나를 부여함.

스웜 모드의 구조:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

 사용자 ──서비스 정의──▶ ┌───────────────────┐
 (이미지·복제 수 등)      │  매니저 (엔드포인트)  │ ◀─ 여러 매니저로 이중화
                        └─────────┬─────────┘
                     컨테이너 실행 계획·지시
              ┌────────────────┼────────────────┐
              ▼                ▼                ▼
         ┌────────┐       ┌────────┐       ┌────────┐
         │ 워커 1  │       │ 워커 2  │       │ 워커 3  │
         │ [태스크]│       │ [태스크]│       │ [태스크]│ ← 태스크 = 워커의 컨테이너
         └────────┘       └────────┘       └────────┘
         스웜(Swarm) = 도커 호스트(노드)들의 클러스터

4.10.3. 서비스와 태스크

4.10.4. 클러스터를 관리하는 도구

4.11. 도커의 주요 명령어

4.11.1. 도커 명령어를 사용할 수 있는 환경

4.11.2. 도커 명령어의 기본

도커 명령어의 구조:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  docker   container   run   -i -t   centos:latest   /bin/bash
    │          │        │      │          │              │
  기본       관리     명령어   옵션      이미지         컨테이너 내
  명령      명령어                                      실행 명령

  옵션: -i  (하이픈 1개 + 영문 1글자)   /   --help  (하이픈 2개 + 영어 단어)

4.11.3. 컨테이너의 시작 / 분리 / 표시 / 정지 / 삭제

작업 명령어 / 조작 비고
시작 docker container run -i 키보드 입력 활성화, -t 셸 프롬프트 표시 활성화
분리 (detach) Ctrl + P → Ctrl + Q 시작한 컨테이너에서 빠져나오는 조작
상태 확인 docker container ls 컨테이너 ID, 이미지 등 확인
정지 docker container kill 실행 중인 컨테이너 정지
정지 포함 전체 표시 docker container ls -a -a = 정지한 모든 컨테이너 표시
삭제 docker container rm 남아 있는 컨테이너 레이어 삭제 
~$ docker container run -i -t centos:latest /bin/bash
참고

컨테이너를 정지한 후에도 컨테이너 레이어는 남아 있음. docker container ls -a로 확인하고 docker container rm으로 삭제함.

4.11.4. 컨테이너 이미지의 생성 / 표시 / 삭제

작업 명령어 비고
생성 docker container commit 실행 중인 컨테이너로부터 이미지 생성
표시 docker image ls 리포지터리, 태그, 이미지 ID 등 확인
삭제 docker image rm

4.11.5. 도커 파일로 컨테이너 이미지 생성

명령어 설명
FROM 기본(베이스) 컨테이너 이미지를 지정
WORKDIR 컨테이너의 작업 폴더를 지정
COPY 파일 및 디렉터리를 컨테이너에 복사
RUN 컨테이너에서 명령을 실행
EXPOSE 컨테이너가 외부에 공개하는 포트를 선언
CMD 기본 시작 명령을 지정

4.11.6. 도커 명령어를 사용하는 곳

4.12. 도커 허브: 컨테이너 이미지를 공유할 수 있는 서비스

4.12.1. 도커 허브란

4.12.2. 컨테이너 레지스트리란

컨테이너 레지스트리의 계층과 푸시 / 풀:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

 ┌────────────────────────────────────────────┐
 │        컨테이너 레지스트리 (도커 허브 등)      │
 │  ┌──────────────────┐  ┌─────────────────┐  │
 │  │ 리포지터리: nginx  │  │ 리포지터리: ...  │  │
 │  │  ├─ 이미지 :latest │  │                 │  │
 │  │  ├─ 이미지 :1.25   │  │ (같은 이미지의   │  │
 │  │  └─ 이미지 :stable │  │  버전들을 태그로) │  │
 │  └──────────────────┘  └─────────────────┘  │
 └──────────────────▲──────────────────┬───────┘
          Push(업로드) │              │ Pull(다운로드)
                       │              ▼
                 ┌──────────────────────┐
                 │   도커 호스트 / 개발자  │
                 └──────────────────────┘

4.12.3. 리포지터리와 태그

4.12.4. 도커 허브 이외의 컨테이너 레지스트리 서비스

클라우드 서비스명
AWS Amazon ECR (Elastic Container Registry)
GCP Container Registry
Azure Azure Container Registry (ACR)

핵심 요약

4-2장. 도커 심화: 격리 기술 · 레이어 · 클러스터 · 명령어 요약:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[컨테이너와 프로세스]
├─ 원칙: 1 컨테이너 = 1 프로세스 ("같은 프로세스로 볼 수 있는가"로 판단)
├─ 장점: 병목만 개별 확장 · 오버헤드 거의 없음 · 경합 상태 방지
└─ 단점: 관리 복잡(→ 오케스트레이션) · 리소스 공유 전제 SW는 부적합

[데이터 지속화]
├─ 볼륨: 도커가 관리하는 이름 붙은 디렉터리 · 여러 컨테이너에 동시 마운트
└─ 바인드 마운트: 호스트 경로를 마운트 · 주로 호스트 ↔ 컨테이너 공유

[격리 기술]
├─ 네임스페이스: 리소스를 '보이지 않게' 격리 (PID · 네트워크 · IPC · 마운트 · UTS)
└─ 컨트롤 그룹(cgroups): 하드웨어 사용량 '제한' (CPU · 메모리 · 디스크 I/O) · 계층 상속

[차분 관리]
├─ 이미지 레이어: 읽기 전용 · 직전 레이어와의 차분만 기록
├─ 컨테이너 레이어: 쓰기 가능 · 컨테이너와 라이프 사이클 동일
├─ 카피 온 라이트: 수정 시 파일을 컨테이너 레이어로 복사한 뒤 변경
└─ 장점(빠른 배포 · 용량 절감) ↔ 단점(잦은 쓰기 시 성능 저하 → 볼륨으로 완화)

[스웜 모드]
├─ 도커 엔진 내장 클러스터 관리 (스웜 = 도커 호스트/노드들의 클러스터)
├─ 역할: 매니저(관리 · 엔드포인트) / 워커(컨테이너 실행)
├─ 서비스(원하는 상태 정의) → 태스크(워커의 컨테이너, 최소 단위)
└─ 현재는 쿠버네티스를 공식 지원하며 방향 전환

[주요 명령어]
├─ 컨테이너: run(-i -t) / ls(-a) / kill / rm , 분리 = Ctrl+P → Ctrl+Q
├─ 이미지: container commit / image ls / image rm
├─ Dockerfile: FROM · WORKDIR · COPY · RUN · EXPOSE · CMD
└─ 예: run -v(마운트) -d(백그라운드) -p(포트 할당)

[도커 허브 / 레지스트리]
├─ 레지스트리 > 리포지터리 > 이미지 (태그: latest · stable …)
├─ 푸시(업로드) / 풀(다운로드) — Docker Registry HTTP API
└─ 그 외: Amazon ECR · GCP Container Registry · Azure ACR

참고 자료

관련 자료:

네비게이션

이전 강 목록
◀ 4-1. 컨테이너를 다루는 도구, 도커(Docker) - 파트 1 목록으로